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(57) Abstract: The invention proposes a network system, comprising a first and a second network, a network control device (CSCF) 
located in the first network and a network address translation device (NAT or NAT-PT) located at a border between the first network 
and the second network; wherein the network control device and the network address translation device are adapted to exchange 
commands of a special control protocol, the network control device is adapted to effect address translation of addresses included in 
the pay load of a data packet by sending (A 1 3) a command of the special control protocol to the network address translation device, 
and the network address translation device is adapted to translate the address received by the command of the special control protocol 
and to forward (A 14) a command of the special control protocol including the translated address to the network control device. The 
invention also proposes a corresponding method. 
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"SIP sessions between IPv4 and IPv6 clients and SIP based 
call setup in 3GPP IP multimedia subsystem with NAT in 

place " 



Field of the invention 

The present invention relates to a network system and a 
10 method for traversing multimedia communication via 
network borders . 



BACKGROUND OF THE INVENTION 

15 

The invention relates to the so-called Session Initiation 
Protocol (SIP) . SIP is a general -purpose tool for the 
initiation, modification, and termination of sessions. 
That is, SIP is an application- layer control (signalling) 

2 0 protocol that can establish, modify and terminate 
multimedia sessions or calls with one or more 
participants. These sessions include Internet multimedia 
conferences, Internet telephone calls, multimedia 
distribution and similar applications. Members in a 

25 session can communicate via multicast or via a mesh of 
unicast relations, or a combination of these.' As a core 
part of its functionality, SIP carries the ports, IP 
addresses and domain names needed to describe the 
sessions it controls. 

30 

SIP can be used to initiate sessions as well as to invite 
members to sessions that have been advertised and 
established by other means. Sessions can be advertised 
using multicast protocols such as SAP, electronic mail, 
35 news groups, web pages or directories, among others. 
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SIP invitations used to create sessions carry session 
descriptions which allow participants to agree on a set 
of compatible media types* SIP supports user mobility by 
5 proxying and redirecting requests to the user's current 
location. Users can register their current location. SIP 
is not tied to any particular conference control 
protocol. SIP is designed to be independent of the lower- 
layer transport protocol and can be extended with 
10 additional capabilities. 

In the following, the SIP invitation is described in more 
detail. A successful SIP invitation consists of two 
requests, INVITE followed by ACK. The INVITE request asks 

15 the callee to join a particular conference or establish a 
two-party conversation. The callee can agree to 
participating in the call by sending a 2 00 OK response. 
In turn, the caller confirms that he has received that 
response by sending an ACK request. If the caller no 

20 longer wants to participate in the call, it sends a BYE 
request instead of an ACK. 

Recently 3 rd Generation Partnership Project (3GPP) has 
selected SIP as the call control protocol for 3G (3 rd 
25 Generation) IP-based wireless networks. 

The limited size that the current IPv4 (Internet Protocol 
version 4) protocol address space can offer has been 
causing difficulties in coping with the explosive 

3 0 increase of the amount of IP addresses needed. This 
situation will culminate with the introduction of 
cellular data services, such as General Packet Radio 
Service (GPRS) and Mobile IP Telephony (MIPT) . For the 
new generation of applications such as Mobile IP 

35 Telephony and push applications, unique addressing and 
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end-to-end client reachability will be fundamental. Using 
IPv4 does not offer a viable solution and IPv6 (Internet 
Protocol version 6) must be considered to be used within 
cellular data services. The 3GPP standardisation 
5 organisation has recently selected IPv6 as the only 
network protocol for the Mobile IP Telephony Network. 
However, the timeframe for changing/upgrading the current 
IPv4 devices to IPv6 is difficult to foresee, thus the 
communication between the legacy IPv4 and the newly 
10 introduced IPv6 devices must be solved. The interworking 
is not limited to simple IP protocol translation (between 
v4 and v6) since there are applications which include 
transport addresses (TA) in the packet payload (eg. SIP, 
FTP) to establish new media or data connections. 

15 

This interworking between different protocols is 
performed by so-called Network Address and Protocol 
Translators (NAT-PT) . A NAT-PT or NAT is a logical 
function which is embedded in a border router which 
20 straddles a public and a private network. The NAT 

translates IP address information from packets which 
traverse the boundary. 

NATs are stateful devices. They generally require a table 
25 to be established listing the active sessions. For each 
session, the particular bindings and translations are 
stored. Sessions are either removed explicitly through 
packets (e.g. TCP FIN bit checked) or are timed out after 
a time period (the case of UDP sessions) . 

30 

Since NATs operate at the IP and transport layers, they 
are insufficient when application layer protocols include 
IP addresses and ports within their payloads. 
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In detail, NAT - PT is an IPv4 -to- IPv6 transition mechanism 
which attempts to provide transparent routing to end- 
nodes in v6 realm trying to communicate with end-nodes in 
v4 realm and vice versa. This is achieved using a 
5 combination of Network Address Translation and Protocol 
Translation. This mechanism does not mandate dual stack 
in end nodes and does not have any special routing 
requirement neither requires tunneling support. This 
mechanism is based on NAT-like address translation and IP 
10 header conversion. 

NAT-PT uses a pool of IPv4 addresses for assignment to 
IPv6 nodes on a dynamic basis as sessions are initiated 
across IPv4 -IPv6 boundaries. The IPv4 addresses are 

15 assumed to be globally unique. NAT-PT binds addresses in 
an IPv6 network with addresses in an IPv4 network and 
vice versa to provide transparent routing for the 
datagrams traversing between address realms. This 
requires no changes to end nodes and IP packet routing is 

20 completely transparent to end nodes. It does, however, 
require NAT-PT to track the sessions it supports and 
mandates that inbound and outbound datagrams pertaining 
to a session traverse the same NAT-PT router. 

2 5 When more IPv6 hosts want to communicate through the 

IPv4 -IPv6 boundary than the available IPv4 addresses 
would allow, NAT-PT must be able to translate not only 
the IP addresses but also the port numbers . The TCP/UDP 
ports of the IPv6 nodes are translated into TCP/UDP ports 

3 0 of the NAT-PT 1 s IPv4 address pool. Such a device is also 

known as Network Address and Port Translator, Protocol 
Translator (NAPT-PT) . 

Hosts in IPv4-realm access IPv6-realm hosts by using 
3 5 Domain Name Server (DNS) for address resolution. A DNS 
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Application Level Gateway (DNS-ALG) must be employed in 
conjunction with NAT - PT to facilitate name to address 
mapping. Specifically, the DNS-ALG must be capable of 
translating IPv6 addresses in DNS queries and responses 
5 into their IPv4 -address bindings, and vice versa, as DNS 
packets traverse between IPv6 and IPv4 realms. 

SIP messages carry the descriptions of the media sessions 
to be established in their payload using the Session 

10 Description Protocol (SDP) . There has been a SIP 

extension defined how to modify the Via header in the SIP 
message body after the message has traversed a NAT. This 
mechanism is called receiver tagging and is intended to 
ensure that the SIP responses are routed back correctly 

15 through NAT . 

As mentioned above, control protocols for establishing 
media sessions like SIP cause problems for NAT-like 
devices, since the addresses for the sessions to be 
20 established are carried in the body of the application 
layer messages. The NAT function in NAT-PT (NAT) is 
application unaware and does not snoop the payload. 
Hence, some additional mechanism is needed for payload 
modification. 

25 

SUMMARY OF THE INVENTION 

Therefore, the object underlying the invention resides in 
30 solving the above-described problem. 



According to the invention, this object is solved by a 
network system, comprising 

a first network and a second network; 
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a network control device located in the first 
network and 

a network address translation device or a network 
address and protocol translation device located at a 
5 border between the first network and the second network; 
wherein 

the network control device and the network address 
translation device (NAT or NAT-PT) are adapted to 
exchange commands of a special control protocol, 

10 the network control device is adapted to effect 

address and possibly protocol translation of addresses 
included in the payload of a data packet by sending a 
command of the special control protocol to the network 
address translation device (NAT or NAT-PT) , and 

15 the network address translation device (NAT or NAT- 

PT) is adapted to translate the address received by the 
command of the special control protocol and to forward a 
command of the special control protocol including the 
translated address to the network control device. 

20 

Alternatively, the above object is solved by a network 
communication method for communication between a first 
network and a second network, wherein in the first 
network a network control device is located, and at the 

2 5 border between the first and the second network a network 
address translation device or network address and 
protocol translation device is located at a border 
between the first network and the second network, the 
network control device and the network address 

30 translating device (NAT or NAT-PT) being adapted to 
exchange a special control protocol; the method 
comprising the steps of 

receiving a message including an address to be 
translated within the payload of the message by the 

35 network control device, 
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sending a command of a special control protocol from 
the network control device to the network address 
translation device, 

translating the address received by the command of 
5 the special control protocol in the network address 

translating device, and binding these two addresses in 
the network translation device for the time of the 
multimedia session, 

sending a command of the special control protocol 
10 including the translated address to the network control 
device . 

By the above system and method it is possible to 
translate addresses which are included in the payload of 

15 data packets, although the network translation address is 
only adapted to translate the addresses of the data 
packets itself. That is, by providing the network address 
translation device with the capability of understanding a 
few additional commands of a special control protocol, 

20 the translation of such addresses can easily be performed 
by an interworking between the network control device and 
the network translation device. 

In particular, the control protocol should comprise a 
25 command, into which the network control device can 

include an address to be translated and by which the 
network address translation device can easily extract the 
address. Thus, the network address translating device can 
easily translate the address without actually working on 
3 0 the application layer. 

Thus, the first and the second network can be operated 
with different versions of the IP network layer protocol, 
and/or a different addressing scheme is used in the first 
3 5 and the second network. The different addressing scheme 



WO 02/09387 



PCT/EPOO/07037 



- 8 - 

could reside in a scenario in which the first network 
uses a private addressing scheme and the second network 
uses a public addressing scheme, for example. Thus, 
according to the invention a multimedia communication can 
5 easily be setup in such a scenario. 

Preferably, the special control protocol is the MEGACO 
(H.248) protocol. In this case, the network address 
translating device needs only to be able to handle a 
10 small subset of the MEGACO commands. For example, the 
ADD, SUBTRACT, and the ServiceChange command are 
sufficient . 

The data packets may include addresses within their 
15 payloads which are part of Session Initiation Protocol 

(SIP) messages. Thus, the addresses which are included in 
SIP INVITE messages, for example, can be easily 
translated by the above system and method. 

2 0 The network control device may be a Call State Control 

Function (CSCF) or a proxy, like a SIP proxy in case SIP 
is used. Since the CSCF or proxy has to perform 
application layer operations anyway, it is seen 
advantageous to let these devices also operate with 
25 respect to the address and protocol translation. 

Furthermore, CSCF may use MEGACO for control ing other 
elements, like circuit switched gateways also. 

The network address translation device may be a Network 

3 0 Address Translator (NAT) or a Network Address Translator 

and Protocol Translator (NAT-PT) . 

The messages exchanged may be used for initiating a 
multimedia communication. Such messages include addresses 
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in their payloads which have to be translated in order to 
initiate such a communication. 

The network address and protocol translation device may 
5 perform a dynamic binding for media addresses which are 
exchanged in the initiation and modification phase of the 
multimedia communication. This binding is only possible 
by performing the above translation of addresses hidden 
in payloads of data packets. 

10 

The network translation device may further comprise a 
Domain Name Server Application Layer Gateway (DNS-ALG) . 
By these means, a DNS query can traverse the network 
border. Thus, name to address mapping is facilitated, and 
15 a domain query traversing the borders can easily be 
performed. 

In particular, in the system addresses are transported in 
the payload of DNS messages, and these addresses have to 
20 be changed at the network borders. It is noted that the 
binding of these addresses may be static in the NAT-PT, 
since they are addresses of network elements, thus the 
performance is not a critical issue in this case. 

25 Moreover, in order to minimise the conversion complexity, 
the SIP message headers should not contain IP- addresses 
as part of SIP-URLs, usage of domain names is preferred 
instead, since domain names do not need any conversion. 



30 



BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention will be more readily understood 
with reference to the accompanying drawings in which: 



35 
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Fig. 1 a network system comprising a Mobile IP Telephony- 
network and Internet, in which a SIP invitation procedure 
is carried out starting from the Internet, according to a 
first embodiment, 

5 

Fig. 2 the network system according to Fig. 1, in which a 
SIP invitation procedure is carried out starting from the 
MIPT network, 

10 Fig. 3 a more detailed illustration of certain procedure 
messages of Fig. 1, 

Fig. 4 a more detailed illustration of certain procedure 
messages of Fig. 2, 

15 

Fig. 5A and 5B a diagram indicating information flow 
between network nodes for a call originated in the 
Internet according to a second embodiment, 

2 0 Fig. 6 A and 6B a diagram indicating information flow 

between the network nodes for a call originated in the 
MIPT network, 

Fig. 7 a diagram illustrating two private networks 
25 connected via a public network according to a third 
embodiment , and 

Fig. 8A to 8D a diagram indicating information flow 
between the network nodes according to the third 

3 0 embodiment shown in Fig. 7. 
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DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 



In the following, the general idea of the invention is 
described . 

5 

As mentioned above, NAT-PTs (NATs) operate at the IP 
(Internet Protocol) and transport layers, and thus they 
are insufficient when application layer protocols include 
IP addresses and ports within their payloads . 

10 

One solution for allowing SIP through NAT-PTs or NAT is 
using an Application Level Gateway (ALG) which 
understands SIP on top of NAT-PT (SIP-ALG) . These devices 
have awareness of the particular application, and can 
15 translate addresses within message bodies. 

Since in this case the proxy and NAT-PT (NAT) are 
collocated, the proxy can have direct control over the 
NAT-PT through some kind of internal API (Application 
20 Programming Interface) . This configuration is 

advantageous in a sense that it does not need to rely on 
the existence of SIP servers within the network. 

However, the disadvantage of this method is that the NAT- 
25 PT (NAT) would not be able to work at the desired speed 
since an ALG is on top of it. This may result in low 
performance and, even more, in dropped calls. 
Furthermore, the NAT-PT (NAT) needs to be upgraded each 
time new extensions to SIP get deployed. This eventually 
30 may become difficult to manage and difficult to support 
within a wide area network. 

Thus, according to the invention, the proxy and NAT-PT 
(NAT) are separated devices. Therefore, an external 
35 control protocol or API (Application Programming 



WO 02/09387 



PCT/EP00/07037 



- 12 - 

Interface) must be used between th - This protocol would 
allow the proxy to instruct the NAT - PT to create or 
delete bindings for the media streams. This allows 
application layer information to be externalised from the 
5 NAT-PT. 

For remotely controlling the NAT-PT (NAT) , according to 
the invention the MEGACO (H.248) protocol is used as 
control protocol between the CSCF and NAT-PT. 

10 

The MEGACO protocol is a protocol used between elements 
of a physically decomposed multimedia gateway. 

In the following some terms of the MEGACO protocol which 
15 are important for the present invention are described in 
short . 

It is noted that a Context, as understood in the MEGACO 
protocol, is an association between a number of 
20 Terminations. The Context describes the topology (who 
hears /sees whom) and the media mixing and/or switching 
parameters if more than two Terminations are involved in 
the association. On the other hand, a Termination, as 
understood in the MEGACO protocol, is a logical entity on 

2 5 a MG (Media Gateway) that sources and/ or sinks media 

and/or control streams. A Termination is described by a 
number of characterizing properties, which are grouped in 
a set of Descriptors that are included in commands. 
Terminations have unique identities (TerminationlDs) , 

3 0 assigned at the time of their creation. 

Descriptors are the parameters to a command. A Descriptor 
consists of a name and a list of items. Some items may 
have values. Next, some Descriptors and their use are 
35 described. 
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The Descriptor 'Stream 1 describes a list of 
Remote/Local /LocalControl descriptors for a single 
stream. 

5 

The Descriptor 'Local 1 contains properties that specify 
the media flows that the MG receives from the remote 
entity. 

10 The Descriptor 'Remote' contains properties that specify 
the media flows that the MG sends to the remote entity. 

In the present invention, basically three MEGACO commands 
are concerned, the ADD command, the SUBSTRACT command and 

15 the ServiceChange command. The ADD command adds a 

termination to a context and can be used to reserve 
resources. The ServiceChangecommand registers controlled 
elements to their controllers.. The SUBTRACT command 
disconnects a Termination from its Context and returns 

20 statistics on the Termination's participation in the 
Context. Thus, it can be used to release resources. 

When a Termination is added to a Context, the value of 
its read/write properties can be set by including the 
25 appropriate descriptors as parameters to the ADD command. 
Properties not mentioned in the command retain their 
prior values. 

According to the present invention, MEGACO is used for 
30 reserving and binding the TAs of the initiated media 
stream. 

Now, the fields in the SIP/SDP (Session Description 
Protocol) message which contain logical names or IP 
35 addresses/port numbers are described. 
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In the following, the relevant SIP header fields are 
described: 

5 - The Contact Header in SIP requests and responses. The 
Contact Header contains a SIP URL (Uniform Resource 
Locator) . SIP URLs can contain an IP address or a 
hostname . 

10 - The Record-Route and Route headers in SIP requests. 
They indicate routing instructions for subsequent 
messaging. 

- The Request URI (Uniform Resource Identifier) in SIP 
15 requests. This field contains a SIP URL. It usually does 

not contain an IP address but a domain name. 

- The Via Headers in SIP requests. They contain IP 
addresses or domain names and port numbers. These 

2 0 addresses are used to forward responses. SIP supports 

receiver tagged via fields. This means that if a request 
arrives from a host, and the source IP address in the 
packet containing the request does not match the address 
in the Via field, the proxy tags the Via field with the 

25 source IP address. This address is used to send 

responses. This feature means that the Via field does not 
need to be translated through NAT-PTs (NATs) . Responses 
are sent to the port in the Via field and not to the 
source port of the message. This means that changes to 

30 the port numbers, made by NAT-PTs, will cause responses 
to be misrouted. 

- Call- ID in a SIP request. This field contains some 
identifier appended to the IP address or hostname of the 

35 machine where the call was originated. This address is 
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never needed for message routing but it is required to be 
globally unique. Two users from two different private 
networks with same private IP addresses should never use 
the same identifier. 

5 

- To and From fields in SIP requests. Theses fields 
contain SIP URLs. Since these fields are used for 
identification of the parties, they should contain domain 
names and not IP addresses. 

10 

The following fields in the SDP part are concerned: 

- The "o field". This field contains the user's host 
name . 

- The "c field" and the "m field" . These fields specify 
the address and port number, respectively, the user 
awaits for media connection. If the message passes 
through a NAT-PT (NAT) , a new mapping with this address 

20 and port must be inserted into the NAT-PT table. 

Thus, when a SIP control connection is to be set up 
through a NAT-PT, the following action must be taken: 

25 The NAT-PT must be instructed to insert a mapping 

containing the transport addresses of the parties for 
media connection found in SDP's c and m fields. The media 
connection can comprise a RTP (Real Time Transport 
Protocol) connection, for example. 

30 

The NAT-PT must not translate the port number in the 
received SIP INVITE message when it translates the IP 
address. Otherwise the 200 OK response to the INVITE 
message will be misrouted by the SIP proxy (see Via 
35 headers above) . 
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In the following, preferred embodiments of the invention 
are described in more detail with reference to the 
accompanying drawings . 

5 

Fig. 1 illustrates a network system comprising an Mobile 
IP Telephony (MIPT) network which is connected to the 
Internet according to a first embodiment. The MIPT 
network uses the IPv6 protocol, whereas the Internet uses 
10 the IPv4 protocol. Hereinafter, setting up an end-to-end 
SIP-session between an end-user residing in the MIPT- 
network and a SIP-client on the Internet is described. 

The scenario is analyzed from three different 
15 perspectives: Domain name resolution, 

SIP-packets traversing the NAT-PT, and required SDP- 
payload modifications, and the usage of MEGACO to 
remotely control the bindings in NAT-PT. 

20 Fig. 1 describes the detailed scenario for a call 
initiated by a SIP-client residing in the v4-only 
Internet as a first embodiment. 

For performing interworking between the two different 
25 networks, the NAT-PT is applied. As illustrated, the NAT- 
PT comprises a DNS-ALG, i.e., a Domain Name System 
Application Layer Gateway. IPv4 name -to- address mappings 
are held in the DNS with so-called "A" -records . On the 
other hand, IPv6 name- to- address mappings are at the 
3 0 moment held in the DNS with so-called "AAAA" records. A 
SIP-client on the Internet may be bound to a SIP server 
in a sense that the domain part of its alias equals to 
the fully qualified domain name of its SIP server. In a 
MIPT network the fundamental concept of mobility assumes 
3 5 that the subscriber address of the mobile user does not 
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reflect the domain name of the CSCF (Call State Control 
Function) it is currently registered to. 

Next, the domain name resolution in a call from the 
5 Internet (the IPv4 network) to the MIPT network (IPv6 
network) is described. 

In the present embodiment, a case is assumed in which an 
IPv4 network user (user A) wants to contact a user from 

10 an IPv6 network (user B) . Thus, user A (having the 

address userA@sipl.nokia.hu, for example) sends a SIP 
INVITE message Al, which is received by a SIP proxy 
(having the address sipl.nokia.hu). The user B to be 
contacted has the address userB@ipt.operator.hu, for 

15 example. 

Before the message can traverse the NAT-PT, a DNS query 
message must be performed, since the addresses found in 
the IP header and in the payload have to be translated, 
20 with the help of a DNS-ALG. The DNS name resolution 

process is shown in Fig. 1 with message numbers A2-A9. 

In detail, in message A2 the SIP proxy sends a name 
resolution request (type A) asking the IP address for 
25 ipt.operator.hu to a DNS having the address nokia.hu, 
which is the DNS of the SIP proxy. 

In message A3 the SIP Proxy's DNS forwards the request to 
its Root DNS. 

30 

In message A4 the Root DNS answers with the address of 
(type A record) MIPT network operator's DNS server. It is 
noted that this needs a correct configuration in the DNS 
system. Since the communication is in the IPv4 network, 
35 the Root DNS must be configured with an IPv4 address from 
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NAT-PT f s address pool pointing to the MIPT network 
operator's DNS server (operator.hu). 



Furthermore, in message A5 the SIP Proxy's DNS server 
5 contacts the DNS server of operator.hu and asks for the 
ipt.operator.hu IP address. NAT - PT recognizes a DNS 
packet based on the fact that its source and/or 
destination port number is 53 (either UDP or TCP) . 



10 In message A6 the DNS-ALG of the NAT-PT modifies the 
Query type from A to AAAA. The NAT-PT changes the 
destination address to the address of the operator's 
internal DNS and translates the source address from IP4 
to "IP4 translated IP6 address". 

15 

In message A7 the operator's internal DNS sends the 
response message (type AAAA) back to the "IP4 translated 
IPG" destination address. It is noted that the routers 
inside the operator's backbone need a static route 
20 configuration: all packets with the destination address 
of type "IP4 translated IP6" must be routed to the NAT- 
PT. 



In message A8 the DNS-ALG intercepts the packet and 
25 modifies the record type from AAAA back to A. It replaces 
the IPv6 address resolved by the operator's internal DNS 
with an IPv4 address from its address pool. It will hold 
the mapping between these two addresses (temporary 
binding) . It is noted that in a flat MIPT network no such 
30 binding is needed, since NAT-PT can be configured to 

route all IP packets coming from the IPv4 network to port 
5060 (SIP messages) to the CSCF(s). NAT-PT changes back 
the "IP4 translated IP6 address" destination address to 
IP4 and puts its address in the source field. It sends 
35 the packet to the SIP proxy's DNS . 
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In message A9 the DNS forwards the DNS Response to SIP 
proxy . 

5 In the scenario above it is assumed that the DNS system 
works in the way it works today. That is, DNS has 
recursive mode enabled only for queries coming from local 
hosts . 

10 Next, the domain name resolution in a call from the MIPT 
network to the Internet is described by referring to Fig. 
2. Similar to the case of Fig. 1, the procedure is 
started by sending a SIP INVITE message in message Bl, 
this time by user B. 

15 

An issue here is how the IPv6 only operator.hu DNS server 
talks to the IPv4 only (Root) DNS server outside the IPv6 
domain. The external Root DNS server needs to point to an 
IPv4 address, part of the IPv4 pool of addresses 

20 available to the NAT-PT. The NAT-PT keeps a one-to-one 

mapping between this IPv4 address and the IPv6 address of 
the internal operator.hu IPv6 DNS server. In the other 
direction, the IPv6 DNS server points to a v6 address 
formed from the IPv4 address of the external IPv4 DNS and 

25 the prefix in use by the IPv6 domain (pref ix : : /96 ) . 

In order to minimize the IPv6 to/from IPv4 translations, 
a DNS server function is proposed in NAT-PT. If this DNS 
server has the recursive mode enabled in the IPv6 domain, 
3 0 no protocol translations are needed during the name 

resolution process. The scenario is described in Fig. 2 
by messages B2-B11. 

These message are basically similar to messages A2-A9 of 
3 5 Fig. 1, thus, only short description is given here. In 
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message B2 , the CSCF sends a DNS query to its DNS (i.e., 
operator.hu) . The DNS forwards this query to the NAT - PT 
in message B3 . The NAT - PT sends the query to its Root DNS 
in message B4 which replies in message B5 . Since also the 
5 Root DNS does not know the domain name, the NAT-PT 

forwards the query to the basic DNS having the domain . hu 
in message B6, which replies in message B7 giving the 
address of the DNS nokia.hu. Thereafter, the NAT-PT 
forwards the query to the DNS nokia.hu in message B8 
10 which replies with message B9 . The NAT-PT forwards this 
message including the address of the SIP proxy to the 
MIPT operator's DNS in message BIO, which forwards it to 
the CSCF in message Bll . 

15 Protocol translation is only done when forwarding message 
B3 to the Root DNS and when message B9 (the DNS Response) 
is forwarded to the operator's DNS. 

Next it is described how the SIP messages (in particular, 
20 the INVITE message) and their SDP-payload traverse the 
NAT-PT. 

SIP carries the session description in its payload using 
SDP. Here it is assumed that the calling party always 
25 puts its complete SDP proposal into the INVITE message, 

and the called party answers with the accepted SDP in the 
2 00 OK message. 

First, a call from the IPv4 network (Internet) to the 
3 0 MIPT v6 network is described. The message numbering in 
Fig. 1 is used when describing the messages in the 
subsections below. 

In the following, the source and destination IP-addresses 
35 of packets carrying the SIP messages are listed. 
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INVITE 

[SIP Proxy to NAT-PT] : dest. IP addr . = IP4 NAT _ PT : 5060 
(Message AlOa) source IP addr . =IP4 S ip proxy :xx 

[NAT-PT to CSCF] : destination IP addr . = IP6 C scf : 5060 
(Message AlOb) source IP addr . = (IP4 S i P PRO xy 

translatedIP6 (port# unchanged) 



10 200 OK 



[CSCF to NAT-PT] : destination IP addr . = ( IP4 S ip proxy :xx) 

translatedIP6 
(Message A15a) source IP addr.= IP6 C scf:5060 



15 [NAT-PT to SIP Proxy]: dest. IP addr . = IP4 S ip proxy : xx 
(Message A15b) source IP addr . = IP4 NAT -pt: 5 06 0 

ACK 

[SIP Proxy to NAT-PT] : dest. IP addr.= IP4 NAT .p T : 5060 
20 (Message A18a) source IP addr.=IP4 S i P proxy:xx 

[NAT-PT to CSCF] : destination IP addr . =IP6 CS cp : 5060 
(Message A18b) source IP addr .= ( IP4 S ip proxy :^x) 

translatedIP6 (port# unchanged) 

25 

xx is an arbitrary TCP or UDP port number. It is noted, 
that for the exchange of the above messages no binding is 
necessary. 

3 0 In the following, the IP-addresses carried in the SDP- 
payload are described. The INVITE and 200 OK messages 
carry the following addresses for media in the SDP part : 
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INVITE 

[SIP Proxy to CSCF] : IP4 me dia advertised in SDP 

(Messages AlOa and AlOb) 

5 [CSCF to IP6 terminal] : IP4 me dia translated IPv6 
(Message All) 

200 OK 

[IP6 terminal to CSCF] : IP6 me dia advertised in SDP 
10 (Message A12) 

[CSCF to SIP Proxy] : IP4 NAT -pt copied from MEGACO REPLY 

(Message A12) 

15 ! IP4 translated IP6 1 is an address of the form 

PREFIX: :ffff:0:IP4, where PREFIX is an identifier 
assigned to the IP6 network . 

It is assumed that both the SIP Proxy and CSCF are 
20 stateful devices, that is, in case of an ongoing call 

setup they can tie a certain SIP message to the correct 
call state machine (i.e., CSCF or SIP proxy) based on the 
call_ID header of the message. 

2 5 The MIPT network needs a configuration that allows the 
routers to route all packets with a destination address 
of PREFIX: :/96 to the NAT-PT. 

Next, the other case, i.e., the call from the MIPT 
30 network to the Internet is described. The message 

numbering in Fig. 2 is used when describing the messages 
in the subsections below. 

The following source and destination IP-addresses of 
35 packets carrying the SIP messages are described: 
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INVITE 

[CSCF to NAT-PT] 
(Message B14a) 



destination IP addr . = ( IP4 Proxy : 5060 ) 
translated IP6 (address obtained by 
name resolution and modified by DNS- 
ALG) source IP addr . =IP6 C scf: YY 



10 



[NAT-PT to SIP Proxy] : 
(Message B14b) 



destination IP addr . = IP4 Proxy : 5060 
source IP addr . = IP4 NA t-pt *yy 
(port# unchanged) 



15 



200 OK 

[SIP Proxy to NAT-PT] : 
(Message B17a) 

[NAT-PT to CSCF] : 
(Message B17b) 



destination IP addr . = IP4 NAX _ PT : yy 
source IP addr.= IP4 Proxy : 5 06 0 

destination IP addr . =IP6 C scf :YY 
source IP addr . = (IP4 Proxy : 5060) 
translated IP6 



20 ACK 



[CSCF to NAT-PT] 
(Message B20a) 



dest. IP addr .= (IP4 Proxy : 5060) 
translated IP6 source IP addr. 

IP6csc F :yy 



25 [NAT-PT to SIP Proxy] : 
(Message B20b) 



destination IP addr . =IP4 Proxy : 5060 
source IP addr . =IP4 NA t-pt :yy 
(port# unchanged) 



The INVITE and 200 OK messages carry the following 
30 addresses for media in the SDP part: 



35 



INVITE 

[IP6 terminal to CSCF] 
(Message Bl) 



IP6 me dia advertised in SDP 
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[CSCF to SIP Proxy] : 
(Messages B14a and B14b) 



IP4 NAT - PT copied from MEGACO REPLY 



200 OK 



5 [SIP Proxy to CSCF] : 



IP4 me dia advertised in SDP 



(Messages 17a and 17b) 

[CSCF to IP6 terminal] : IP4 me dia translated IPv6 
(Message B18) 

10 

According to the invention, the MEGACO (H.248) protocol 
is used for the CSCF to externally control the NAT-PT, 
which is described in the following with reference to 
Figs . 3 and 4 . 

15 

This requires MEGACO to be implemented in the NAT-PT. 
However, a very basic implementation should be 
sufficient, since only a very small subset of MEGACO 
protocol's capabilities will be used. This subset is 

2 0 presented below. 

It is noted that in the following detailed message 
listings additional comments are marked by 1 //■-. 

25 Firstly, a registration procedure is described by which 
the NAT-PT registers for MEGACO control with the CSCF. 

The NAT-PT shall be able to register with the CSCF for 
MEGACO- control . This registration is conducted by means 

3 0 of sending a ServiceChange command, and the CSCF may 

accept the registration attempt with a ServiceChangeAck 
reply. It is noted that these registration procedure is 
not illustrated in the figures. 
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The NAT-PT sends the following message to CSCF in order 
to register : 

MEGACO/1 [AB.CD.EF: : 12 .34 . 99] //IPv6 address of NAT-PT 
5 Transaction = 9999 { 
Context = - { 

ServiceChange = ROOT {Services { 
Method=Restart , 

ServiceChangeAddress=55555 , Prof ile=ResNAT/l} 

10 } 

} 

} 

CSCF sends a reply to NAT-PT accepting the registration: 

15 

MEGACO/1 [AB.CD.EF: : 12 .34 .56] :55555 //IPv6 addr . of CSCF 
Reply = 9999 { 

Context = - {ServiceChange = ROOT { 

Services {ServiceChangeAddress=55555 / Prof ile=ResNAT/l} } } 

20 } 

Next, it is described how the CSCF controls the address- 
binding in NAT-PT with MEGACO. 

25 The NAT-PT realizes only ephemeral type of terminations, 
this also means that the TerminationID and the local 
transport address in the NAT-PT to be used for the 
session are allocated by the NAT-PT itself, and returned 
to the controlling CSCF in the reply message. The CSCF 

3 0 initiates the binding request in NAT-PT by sending an ADD 
command, and receives a TA from NAT-PT to be used for the 
session in the reply message. 

With reference to Fig. 3, a call from the Internet to the 
35 MIPT network is described. Fig. 3 shows the scenario as 
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described in Fig. 1 from MEGACO point of view. Thus, the 

message numbering in Fig. 1 is used when describing the 
MEGACO messages below in detail. 

5 It is noted that the media- IP -address or media TA 
(Transport Address) of user B is 12.34.01:1111. In 
message A12, user A sends a SIP 2000 OK message. The SDP 
part thereof includes in field c the media-IP-address, 
i.e., AB.CD.EF: : 12 .34. 01. Field m includes the media 
10 port, which is 1111 in this example. 

In Message A13 , a MEGACO ADD message is sent from the 
CSCF to the NAT-PT. Thus, as mentioned above, a 
termination is added to the context. 



15 
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Message A13 : 

MEGACO/1 [AB. CD. EF : : 12 . 34.56] : 55555 //IPv6 address of 

CSCF 

Transaction = 50001 { 
5 Context = $ { 

Add = $ { Media { 
Stream = 1 { 

LocalControl {Mode = SendReceive} }}, 

}, 

10 Local { 

v=0 

c=IN IP4 $ 
m=audio $ RTP/AVP 4 
a=ptime : 3 0 
15 } , 

Remote { 

v=0 

c=IN IP6 media- IP- address of UserB //The media IP- 
address and media- 
2 0 port of UserB is 

copied from the SDP 
part of the 2 00 OK. 
m=audio madia-port RTP/AVP 4 //RTP profile for 

G.723 is 4 

25 a=ptime:30 

} 

} 

} 

} 

30 } 
} 

Thus, the c and m fields which has been send by the SIP 
200 OK message A12 are copied in the c and m fields in 
35 the MEGACO ADD message A13 . 
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After receiving message A12, the NAT-PT selects an 
address from its address pool to be bound to the address 
received in message A12 . 

5 

In message A14, the NAT-PT replies to the CSCF by sending 
a MEGACO REPLY message. Therein, the 1 IP4 translated IP6 1 
obtained by the NAT-PT is included in field c. This new 
media IP-address is in this example 111.111.111.1. 

10 

Message A14 : 

MEGACO/l [AB.CD.EF: : 12 . 34 . 99] : 55555 // IPv6 - address of 

NAT-PT 

Reply = 50001 { 
15 Context = 50 0 0 { 

Add = 0000l{ 
Media { 

Stream = 1 { 

Local { 

2 0 v=0 

c=IN IP4 111.111.111.1 //CSCF puts this media IP- 

address and port into the 
SDP part of the 2 00 OK. 

m=audio 1111 RTP/AVP 4 } 
25 } 

} 

} 

} 

} 

30 

Thereafter, the SIP 200 OK message is forwarded from the 
CCSCF to the NAT-PT in message A15a. This SIP 200 OK 
message now includes in field c the media-IP-address as 
required for user A. As shown in Fig. 1, the SIP 200 OK 

3 5 message is forwarded from the NAT-PT to the SIP proxy in 
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message A15b, and the SIP 200 OK message is forwarded in 
message A16 from the SIP proxy to user A. 



User A acknowledges the 2 00 OK message by sending an ACK 
5 in message A17. This message is first sent to the SIP 

proxy, which forwards it to the NAT-PT. Here, the address 
is translated and thereafter, the ACK is forwarded to the 
CSCF in message A18b. Finally, the CSCF forwards the ACK 
to user B in message A19. Thereafter, the media flow can 
10 be started. 



In the following, with respect to Fig. 4 the scenario of 
Fig. 2 is described from MEGACO point of view in detail, 
wherein the message numbering in Fig. 2 is used. 

15 

As described above in conjunction with Fig. 2, in message 
Bl the user A sends a SIP INVITE message in order to 
initiate a media session with user A. The SIP INVITE 
message is sent to the CSCF. In particular, in the SDP 
2 0 part thereof, the media IP-address and port are included, 
similar as in Fig. 3. 



In message B12 , a MEGACO ADD message is sent to the NAT- 
PT. 

25 
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Message B12 : 

MEGACO/1 [AB.CD.EF: : 12. 34. 56] : 55555 
Transaction = 50001 { 
Context = $ { 
5 Add = $ { Media { 

Stream = 1 { 

LocalControl {Mode = SendReceive} }}, 

Local { 

10 v=0 

c=IN IP4 $ 

m=audio $ RTP/AVP 4 

a=ptime : 3 0 

}, 

15 Remote { 

v=0 

c=IN IP4 media- IP- address of UserA //The media IP- 
address and media- 
port of UserA is 
20 received in the 

SDP part of the 
INVITE. 

m=audio media -port RTP/AVP 4 
a=ptime : 3 0 
25 } 

} 

} 

} 

} 

30 } 



In message B13 , the NAT-PT replies to the CSCF with a 
MEGACO REPLY message* In this message the ,! IP4 for IP6 
address" is included in field c, similar to the example 
35 of Fig. 3. 
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Message B13 : 

MEGACO/1 [AB.CD.EF: : 12. 34. 99] : 55555 
Reply = 50001 { 
5 Context = 5000 { 

Add = 0000l{ 
Media { 

Stream = 1 { 

Local { 

10 v=0 

c=IN IP4 111.111.111.1 //CSCF copies this media 

IP-address and port into 
the SDP part of the 
INVITE . 

15 m=audio 1111 RTP/AVP 4 
} 

} 

} 

} 

20 } 
} 

By the above-described embodiment, SIP messages and the 
media sessions it initiates can be managed to get through 
25 a NAT-PT. A DNS ALG function is needed and a DNS server 
function with recursive mode enabled is recommended in 
NAT-PT. 

For remotely controlling the dynamic address bindings in 
30 NAT-PT, a CSCF using MEGACO is used, as mentioned above. 

Thus, the CSCF must be able to handle both type of IP 
addresses (IP4 or IP6) an SDP message may contain. It 
must be able to translate an IP4 address to an ' IP4 
35 translated IP6' when needed. When updating the Via- 



WO 02/09387 PCT/EP00/07037 

- 32 - 

header, the CSCFs must use their domain name and not IP 
addresses. CSCFs should tag SIP messages (the VIA header) 
when messages arrive from NAT-PT and contain IP addresses 
instead of domain names (receiver tagging) . A simple 
5 subset of the controller side MEGACO has to be 

implemented as described in conjunction with Figs. 3 and 
4. 

For the NAT-PT, a simple subset of the gateway side of 
10 MEGACO has to be implemented as described in conjunction 
with Figs- 3 and 4. Furthermore, a DNS-ALG has to be 
implemented . 

As a second embodiment, a SIP scenario for an example of 
15 a Mobile Terminated (MT) call from the Internet is 
described. 

According to the second embodiment, it is assumed that a 
first user located in the Internet requests a call to a 
20 second user located in a private network. The information 
flow between the network nodes concerned is illustrated 
in Fig. 5A and 5B . It is noted that Fig. 5B is a 
continuation of Fig. 5A. 

25 As already described above with respect to the first 
embodiment, the name space and DNS records must be 
configured so that all incoming requests for users within 
the private network arrive at the NAT. If the company is 
named iptl.mipt.hu, this implies that the SIP URLs 

3 0 published externally for users of iptl.mipt.hu should be 
of the form sip :user@iptl .mipt . hu. DNS records must be 
configured so that a lookup of iptl.mipt.hu results in 
the address of the NAT (or NATs , when there are more than 
one to support load balancing) . 

35 
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An INVITE message arrives at the NAT (intended for the 
proxy) when a call is to be set up to a user inside the 
network. The NAT does only have to rewrite the 
destination IP address of the packet to the private 
5 address of the proxy (I-CSCF, i.e., the Interrogating 
Call State Control Function) . 

Address bindings are not created for the media streams in 
the NAT at this time. A NAT will not need to modify any 
10 of the fields of the message. The request is forwarded to 
the proxy (I-CSCF) . All of the SIP level details 
regarding NAT processing are done in the proxy (I-CSCF) . 

That is, the VIA header is tagged with the TA address of 
15 NAT. Furthermore, the Record Route field is updated. The 
c and m fields in the SDP part of the INVITE message are 
rewritten to a TA from the private address space (this 
must be asked from the NAT). The proxy (i.e., the I-CSCF) 
records the original (c, m) fields and the changed (c 1 , 
20 m 1 ) fields. 

The message is forwarded either to the user (if I-CSCF is 
the S-CSCF for that MIPT user) or to the next proxy (S- 
CSCF) which forwards it to the user. 

25 

When a 2 00 OK response arrives back to the proxy (I-CSCF) 
from inside (based on the via headers) , the proxy 
examines the SDP and notes the IP address and port the 
inside user awaits the media session on. It asks for a 
30 globally routable TA from the NAT and rewrites the SDP 
fields according to the received information. The OK is 
then forwarded to NAT, 

When the ACK arrives for the 2 00 OK, it will pass through 
35 the NAT, and arrive at the proxy. The proxy identifies 
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the call based on the call__ID 
bindings from the NAT for the 
then forwarded further. 
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and request the address 
media session. The ACK is 



5 In the following, the above procedures are described in 
more detail with reference to the information flow 
diagram shown in Fig. 5A and 5B . In this scenario it is 
assumed that the Via and Route fields contain IP 
addresses instead of domain names, so no DNS queries are 
10 needed inside the private network. Furthermore, it is 
noted that no security issues are considered. 



In the illustrated example, a first user, e.g., a user 
Kati located in the Internet wishes to establish a 
15 multimedia call with a user Jani located in a private 
network who has the domain name iptl.mipt.hu, as 
described above. 

In message CI, the user Kati sends a SIP INVITE message. 

20 This message is forwarded to the corresponding SIP proxy. 
The SIP proxy has to find out the IP address of 
iptl.mipt.hu. This is effected by sending a DNS query to 
a DNS in message C2 . The DNS responds in message C3 by 
sending the IP address, which is in this example 

25 110.1.1.1. This m is the IP address of the NAT of the 

private network. Thus, the SIP proxy forwards the INVITE 
message to the NAT in message C4 . 



The NAT translates the IP address and port in the packet 
3 0 header for this signalling connection in order to allow 
SIP packets passing through the NAT. In message C5 , the 
NAT forwards the SIP INVITE message to the default CSCF, 
i.e., an Interrogating CSCF (I-CSCF) . 
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The I-CSCF updates the VIA Header using receiver tagging. 
That is, the I-CSCF tags the Via filed with the source IP 
address of the I-CSCF. 

5 In message C6 , the I-CSCF asks the HSS for the S-CSCF of 
Jani. The HSS returns the S-CSCF of Jani in message C7 to 
the I-CSCF. By using this information, the I-CSCF 
forwards the SIP INVITE message to the S-CSCF in message 
C8 . The S-CSCF, in turn, forwards the SIP INVITE message 

0 to the user Jani . 

In case the user agrees to the media session to be 
initiated, he sends a SIP OK message (i.e., SIP 2000 OK) . 
This message is sent to the S-CSCF in message C10 and 
5 forwarded to the I-CSCF in message Cll. 

The I-CSCF sends a MEGACO ADD command to the NAT in 
message C12 . Similar as in the first embodiment, a public 
TA (Transport Address) is obtained, which is sent from 
0 the NAT to the I-CSCF in a reply message. After receiving 
the public TA, the I-CSCF overwe4rites the media address 
in the SDP part with the public TA. Thereafter, the SIP 
OK message is forwarded to the NAT in message C13 . 

5 In the NAT, the SIP OK message traverses from the MIPT 
network to the public Internet and is forwarded to the 
SIP proxy in message C14 . The SIP OK message is then 
forwarded to user Kati in message C15. 

0 Kati acknowledges the OK from Jani by sending a SIP ACK 
message to the SIP proxy in message C20. This message is 
forwarded to the NAT in message C17 . IN message C18, the 
NAT forwards the SIP ACK message to the I-CSCF. 
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Then, the MEGACO MODIFY command is sent to the NAT in 
message C19. Thereby, the NAT is instructed to bind media 
addresses. Thus, a dynamic binding of the addresses is 
achieved, which is memorised in a NAT table. 

5 

The SIP ACK message is forwarded to user entity in the 
MIPT network, i.e., to Jani in messages C20 and C21. 
Thereafter, the media stream is started in message C22 . 
In the NAT, IP addresses and UDP port s are translated 
10 according to the bindings in the NAT table. 

It is noted that according to the above- illustrated 
embodiment, NAT decisions and bindings are still needed 
when translating addresses in the header of the IP 
15. packets for the signalling messages (INVITE, OK, ACK) . 

Next, a MO (Mobile Originated) call to the Internet is 
described by referring to Figs. 6A and 6B. 

2 0 When a user located in the MIPT network (i.e., Jani) 

makes a call, the CSCF acts as a local outbound proxy. If 
NAT is in use at the network boundary, the following 
operations are performed by the CSCF: 

25 The INVITE message is analyzed at SIP level. The IP 

addresses and ports in the SDP are removed. A globally 
routable TA address is requested from NAT. This address 
is inserted into the SDP. When the OK arrives for this 
INVITE, CSCF notes the TA in the SDP. When ACK arrives 

3 0 from the user inside the MIPT network, CSCF instructs NAT 

for the media flow binding. 

If a Contact field is inserted into the INVITE message 
and this field contain a different address than the FROM 
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field, bindings must be created for both addresses in 
NAT. 

The call scenario is shown in Figs. 6A and 6B. 

5 

In message Dl, the user Kati sends a SIP INVITE message. 
This message is forwarded to the CSCF of Kati, i.e., the 
O-CSCF. The O-CSCF has to find out the IP address of 
sip.hu domain. This is effected by sending a DNS query to 
10 an iDNS (i.e., the internal DNS of the MIPT network, 

i.e., the iptl.mipt.hu domain) in message D2 . The iDNS 
responds in message D3 by sending the IP address. 

In message D4 , the O-CSCF asks for a public TA by sending 
15 a MEGACO ADD command to the NAT. The NAT replies with the 
public TA address, as described above in first 
embodiment. Thus, the O-CSCF rewrites the media private 
TA address contained in the SDP part of the SIP INVITE 
message to the public TA address provided by the NAT. 
20 Both addresses are memorised. 

Thereafter, the O-CSCF forwards the SIP INVITE message 
(now to sip.hu proxy) to the NAT. In turn, the NAT 
translates the private TA to the public TA address for 
25 this message. Both addresses are bound to each other. 

The NAT forwards the SIP INVITE message to the SIP proxy 
in message D6 which forwards it to the user located in 
the Internet , i.e., Kati in message D7 . 

30 

If Kati is willing to accept the invitation to the media 
session of Jani, Kati sends a SIP 200 OK in message D8 . 
This message is received by the SIP proxy, which forwards 
the SIP 200 OK message to the NAT in message D9 . 
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The NAT translates the public TA address to the private 
TA address according to the previous binding. Thereafter, 
the SIP 2 00 OK message is forwarded to the O-CSCF in 
message D10. The O-CSCF notices the media address 
5 contained in the SDP part of the SIP 200 OK message and 
forwards the message to Jani in message Dll. 

Jani acknowledges the 200 OK message of Kati by sending a 
SIP ACK in message D12 . This message is received by the 
10 O-CSCF which instructs the NAT for media binding by 
sending a MEGACO MODIFY command in message D13 . 

Thereafter, the O-CSCF forwards the ACK to the NAT in 
message D14 , which forwards this message (after 
15 performing the above-described address translation) to 

the SIP proxy in message D15. The SIP proxy forwards the 
SIP ACK to user Kati in message D16 . 

The flowing of the media stream can be started, as shown 
20 in message D17 . The NAT translates the IP address and the 
UDP port according to the binding in the NAT table. 

Hereinafter, a third embodiment is described in which a 
call between two UE (User Entities) from different MIPT 

25 networks is illustrated. The two private networks are 

connected via the public Internet. In this case, the two 
private networks reach each other by sending the messages 
to the other network's public address. This scenario is a 
combination of the previous two described in the second 

30 embodiment with reference to Figs. 5 and 6. 

Fig. 7 shows the network scenario for such an end-to-end 
SIP call through NATs at the network borders. In this 
example, the first private network is referred to as 
35 network A, in which user Jani is located. This network 
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can have the domain sonera.fi, for example. The second 
private network is referred to as network B, in which 
user Kati is located. This network can have the domain 
pannon.hu, for example. At the border between network A 
5 and the public Internet, a NAT1 is located, whereas at 
the border between network B and the public Internet, a 
NAT 2 is located. 

Fig. 8A to 8D shows the information flow between the 
10 network nodes. The messages are indicated in Fig. 7 and 
in Figs. 8A to 8D by the same reference characters. 

The messages El and E2 and E5 to E7 basically correspond 
to the messages Dl to D6 in Fig. 6A, thus, a detailed 
15 description thereof is omitted. 

However, in this example the DNS query is extended. That 
is, it is assumed that the query to the DNS of the 
network A fails. Thus, in message E3 , the DNS query is 
2 0 forwarded to an eDNS (external DNS) located in the public 
Internet. The eDNS replies in message E4 with the 
requested address. The DNS of the network A forwards the 
DNS response to the O-CSCF, similar as in message C3 of 
Fig. 6A. 

25 

In message E7, the SIP INVITE message is forwarded to 
NAT1, wherein the destination TA of IP packets is changed 
to the I-CSCF TA address. The NAT1 translates the private 
source TA address to the public TA source address for 
30 this message. The NAT1 binds the addresses. The SIP 

INVITE message is then forwarded to the NAT 2 in message 
E8 . 

The NAT2 translates the public source TA address to the 
35 private source TA address. As NAT1 does, also NAT 2 binds 
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the addresses. In message E9 , the SIP INVITE message is 
forwarded to the default CSCF in the network B, i.e., the 
I -CSCF. The I -CSCF updates the Via Header using receiver 
tagging, as described above. The I -CSCF starts a location 
5 query in order to obtain the S-CSCF of user Kati . Thus, 
it sends message E10 to the HSS (Home Subscriber Server) , 
which replies in message Ell with the address of the S- 
CSCF. The I -CSCF notices the public TA address for media. 
Thereafter, it forwards the SIP INVITE message to the S- 
10 CSCF in message E12, which forwards the SIP INVITE 
message to user Kati in message E13 . 

If the user is willing to accept the requested media 
session, he sends a SIP 200 OK in message E14 . The 
15 process for forwarding this message to the NAT2 are 

similar to that shown in Figs . 5A and 5B with respect to 
messages C10 to C13 . Thus, a detailed description of 
messages E14 to E17 is omitted here. 

20 The NAT 2 translates the private source TA address to the 
public source TA address and forwards the SIP 2 00 OK 
message to the NAT1 via the public Internet. The NAT1, in 
turn, translates the public destination TA address to the 
private destination TA address and forwards the SIP 200 

25 OK message to the O-CSCF in the Network A in message E19 . 

The following messages E20 to E23 correspond to the 
messages Dll to D14 . That is, the NAT1 receives the SIP 
ACK message from user Jani in message E23 . 

30 

The NAT1 translates the private source TA address to the 
public source TA address and forwards the SIP ACK message 
based on the route header to NAT2 in message E24 . The 
NAT2 again translates the public source TA address to the 
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private source TA address. Then, it forwards the SIP ACK 
to the I-CSCF in the network B in message E25. 



In message E26, the I-CSCF sends a MEGACO MODIFY command 
5 to the NAT2, in which the NAT is instructed for media TA 
binding* Thereafter, the SIP ACK message is forwarded 
from the I-CSCF to user Kati in message E27. 

Then, the media stream can be started, as shown in 
10 messages E28. When traversing the border between the 

network B to the public Internet, the NAT2 translates the 
IP address and the UDP port according to the binding in 
the NAT table of NAT2 . On the contrary, when traversing 
the border between the public Internet and the network A, 
15 the NAT1 translates the IP address and the UDP port 
according to the binding in the NAT table of NAT1 . 

In the following, some examples for the SIP messages in 
the present embodiment are described in more detail by 
2 0 using the numbering of the previous signalling diagram. 
It is noted that comments in the listing of the messages 
are started with *//' . 

Message El ; Jani to CSCF: 
25 INVITE sip:kati@ocscf. iptl.mipt.hu SIP/2.0 

Via: SIP/2. 0/UDP 10.18.66.1 //originating terminal 1 s 

private TA addr. 
From: Jani <sip : j ani@iptl . mipt . hu> 
To: Kati <sip :kati@ipt2 .mipt .hu> 
30 ALSI: sip: 244910000020001@iptl.mipt.hu 

Call-ID: 12231131@10 . 18 . 66 . 1 //originating terminal's 

private TA addr. 

Cseq: 1 INVITE 

Cont en t - Typ e : app lication/sdp 
35 Content -Length: 
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v=0 



o=jani 76525365 41540546 IN IP4 10.18.66.1 
s=Call Invitation 



5 



m=audio 34 56 RTP/AVP 0 



c=IN IP4 10.18.66.1 



//IP addr. the user awaits 

the media 
//RTP port the user awaits 
the media 



10 Messages E7 / E8 / E9: O-CSCF to I-CSCF: 
INVITE sip :kati@ipt2 .mipt .hu SIP/2.0 

Via: SIP/2. 0/UDP 10.123.61.2 //O-CSCF. iptl .mipt .hu IP 



Via: SIP/2. 0/UDP 10.18.66.1 
15 From: Jani <sip : j ani@iptl . mipt . hu> 
To: Kati <sip : kat i@ipt2 .mipt . hu> 
Call- ID: 1231131@10 .18.66.1 
Cseq: 1 INVITE 

Content-Type : application/ sdp 
2 0 Content -Length: 

v=0 

o=jani 76525365 41540546 IN IP4 10.18.66.1 
s=Call Invitation 
25 c=IN IP4 152.12.61.2 //NAT1 public IP addr. 

m=audio 23 21 RTP/AVP 0 //NAT1 UDP port 

Message E12 : I-CSCF to S-CSCF 
INVITE sip:kati@scscf . ipt2 .mipt .hu SIP/2 . 0 
30 Via: SIP/2. 0/UDP 172.16.34.2 //ipt2's I-CSCF private 



Via: SIP/2. 0/UDP 10.123.61.2; received=199 . 172 . 136 . 3 



addr . 



addr. 



//receiver tagging, NAT 2 public addr. 



35 



Via: SIP/2. 0/UDP 10.18.66.1 

From: Jani <sip : j ani@iptl .mipt .hu> 
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To: Kati <sip :kati@ipt2 .mipt .hu> 
Call -ID: 12 31131010 . 18 . 66 . 1 
Cseq: 1 INVITE 

Content-Type : application/sdp 
5 Content -Length: 14 7 



v=0 

o=jani 76525365 41540546 IN IP4 10.18.66.1 
s=Call Invitation 
10 c=IN IP4 152.12.61.2 

m=audio 2321 RTP/AVP 0 



It is noted that the messages E6 and E16 are MEGACO ADD 
types of messages, whereas the messages E22 and E26 are 
15 MEGACO MODIFY types of messages. 

As a modification of the third embodiment , the two 
private networks can be connected directly via a NAT. 
Both networks may use the same private address space. 

20 

This is basically the same scenario as above. However, 
the only difference is that the NAT needs a DNS ALG (as 
described in the first embodiment) . The DNS responses are 
caught by the DNS ALG and the private IP address 
25 contained in the message is rewritten to an IP address 

from a separate address range, which is pre -configured in 
the NAT. 

Thus according to the above -described embodiments, a SIP 
3 0 proxy or a CSCF can remotely control a regular NAT-PT or 
NAT. 

Therefore, the proxy (or CSCF) and the NAT-PT (NAT) can 
be separated, and a special control protocol can be used 
35 between them. This protocol allows the proxy to instruct 
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the NAT - PT to bind or delete holes for the media streams. 
This allows application layer information to be 
externalised from the NAT-PT. 

5 By placing the application layer awareness in the proxy 
rather than in NAT-PT, the NAT-PT 1 s performance can be 
optimised, and newly deployed SIP extensions would only 
affect SIP proxies. 

10 The special control protocol can preferably be the MEGACO 
(H.24 8) protocol. Hence, it has been shown above how SIP 
can traverse network address and protocol translators 
(NAT-PT) and also domain name resolution (DNS) issues 
with protocol translation have been taken under 

15 consideration. 



Thus, according to the invention SIP sessions between 
IPv4 and IPv6 clients and SIP based call setup in 3GPP IP 
multimedia subsystem with NAT in place can easily be 
2 0 performed. 

The above description and accompanying drawings only 
illustrate the present invention by way of example. Thus, 
the embodiments of the invention may vary within the 
25 scope of the attached claims. In particular, the 
different embodiments can be arbitrarily combined. 
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Claims 

1. A network system, comprising 
5 a first and a second network; 

a network control device (CSCF) located in the first 
network and 

a network address translation device (NAT) or a 
network address and protocol translation device (NAT-PT) 

10 located at a border between the first network and the 
second network; wherein 

the network control device and the network address 
translation device (NAT or NAT-PT) are adapted to 
exchange commands of a special control protocol, 

15 the network control device is adapted to effect 

address and possibly protocol translation of addresses 
included in the payload of a data packet by sending (A13; 
B12) a command of the special control protocol to the 
network address translation device (NAT or NAT-PT) , and 

20 the network address translation device (NAT or NAT- 

PT) is adapted to translate the address received by the 
command of the special control protocol and to forward 
(A14; B13) a command of the special control protocol 
including the translated address to the network control 

25 device. 

2. The network system according to claim 1, wherein the 
special control protocol is the MEGACO (H.248) protocol. 

30 3. The network system according to claim 1, wherein the 
data packets including addresses within their payloads 
are part of Session Initiation Protocol (SIP) messages. 
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4. The network system according to claim 1, wherein the 
network control device is a Call State Control Function 
(CSCF) . 

5 5. The network system according to claim 1, wherein the 
network control device is a proxy. 

6. The network system according to claim 1, wherein the 
network address translation device is a Network Address 

10 Translator (NAT) . 

7. The network system according to claim 1, wherein the 
network address and protocol translation device is a 
Network Address Translator and Protocol Translator (NAT- 

15 PT) . 

8. The network system according to claim 1, wherein the 
messages exchanged are used for initiating a multimedia 
communication. 

20 

9. The network system according to claim 8, wherein the 
network translation device performs a dynamic binding for 
media addresses which are exchanged in the initiation and 
modification phase of the multimedia communication. 

25 

10. The network system according to claim 1, wherein the 
network translation device further comprises a Domain 
Name System Application Layer Gateway (DNS-ALG) . 

30 11. A network communication method for communication 

between a first network and a second network, wherein in 
the first network a network control device (CSCF) is 
located, and at the border between the first and the 
second network a network address translation device or 

35 network address and protocol translation device is (NAT- 
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PT; NAT) located at a border between the first network 
and the second network, the network control device and 
the network address translating device (NAT or NAT-PT) 
being adapted to exchange a special control protocol; the 
5 method comprising the steps of 

receiving (A12 ; Bl) a message including an address 
to be translated within the payload of the message by the 
network control device, 

sending (A13; B12) a command of a special control 
10 protocol from the network control device to the network 
address translation device, 

translating the address received by the command of 
the special control protocol in the network address 
translating device, and binding these two addresses in 
15 the network translation device for the time of the 
multimedia session, 

sending (A14 ; B13) a command of the special control 
protocol including the translated address to the network 
control device - 

20 

12. The method according to claim 11, wherein the 
special control protocol is the MEGACO protocol. 

13. The method according to claim 11, wherein the data 
25 packets including addresses within their payloads are 

part of Session Initiation Protocol (SIP) messages. 

14. The method according to claim 11, wherein the 
network control device is a Call State Control Function 

3 0 (CSCF) . 

15. The method according to claim 11, wherein the 
network control device is a proxy. 
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16. The method according to claim 11, wherein the 
network address translation device is a Network Address 
Translator (NAT) . 

5 17. The method according to claim 11, wherein the 
network address and protocol translation device is a 
Network Address Translator and Protocol Translator (NAT- 
-PT) . 

10 18. The method according to claim 11, wherein the 

messages exchanged are used for initiating a multimedia 
communication . 

19. The method according to claim 18, further comprising 
15 the step of performing a dynamic binding for media 
addresses which are exchanged in the initiation and 
modification of the multimedia communication in the 
network address translating device (NAT or NAT-PT) . 

20 20. The method according to claim 11, further comprising 
a Domain Name System Application Layer Gateway (DNS-ALG) 
function for translating domain names to network . 
addresses when traversing the border between the first 
network and the second network. 

25 
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